I'm wondering why this needs to be required dynamically. Could we instead import { registerBlock as registerLayoutGridBlock } from '../block-experiments/blocks/layout-grid/src'; here, and invoke it under __DEV__? If this is for the incidental idempotency given by require.cache, maybe we can explicitly make this idempotent by setting a flag in the file-level closure here?

I believe that a require is necessary because metro doesn't support require imports just yet. See #2582 (comment)

That comment refers to why we would use require() instead of import(), which are both dynamic. What I'm wondering is, why are we aiming for this to be dynamic? I.e. why not a static import at the top of the file, and dynamically register the block under __DEV__?

Good question! I think part of the reason why I included it like this is so that we don't load the js script when the flag is not set. but since we are not downloading the js I guess this part doesn't really matter.

It would be cool to explore something like this down the road for lazy-loading / code splitting.

I just had a thought about the relative import path used here. Not suggesting a change, but wondering if there's a way to scope this (similar to how we resolve @wordpress dependencies) such that a future change in project structure wouldn't require any changes here. Something like '@something/blocks' 🤔

If there's too much "magic" in the module resolution configuration, perhaps we'd still achieve a similar effect by importing from an index at a higher level in ../block-experiments? It feels like "reaching deep into" the path here will be brittle to structure changes in the dependency. (This comment might belong there as well as here 😅 ) Wdyt?

I think that is a great idea but I am not sure how to go about doing that. Any suggestions?

The second idea would just involve creating an index.js (or possibly index.native.js) file in ../block-experiments/blocks/ and re-exporting the block registration there. This would shift the responsibility of maintaining the deeper path traversals to the dependency, which probably makes more sense, since that's where the structure changes would occur.

Regarding the module resolution magic, there is a plugin that might be worth investigating for this purpose, but I haven't tried it out. It essentially allows you to create an alias for the imports.

Regarding the module resolution magic, there is a plugin that might be worth investigating for this purpose, but I haven't tried it out. It essentially allows you to create an alias for the imports.

I've used that plugin in every React native project I've worked on, it's very useful. Also very easy to set up (usually).